1 . Field of the Invention
This invention relates to computer software, and more particularly, to a definition for a consistent interface for the native methods called by Component Peer classes within the abstract windowing toolkit (AWT), a software interface between platform independent Java applications and a particular hardware platform. This leads to a common set of Peer classes for all supported platforms, which can be ported without modification to heterogeneous computer systems.
2. Description of the Related Art
The continuing proliferation of faster and more powerful computers has been accompanied by an increase in the use of graphical user interfaces. A graphical user interface (or, GUI) offers many advantages over traditional text-based interfaces. A graphical interface may allow multiple application programs to present output simultaneously, each in a distinct window. Thus, it is not necessary to halt one application in order to interact with another. Instead of entering text-based commands and parameters, the user selects icons with a pointing device, such as a mouse. This is faster, easier and less error prone than making these selections using the keyboard.
The development of object-oriented programming languages has accompanied the increased popularity of GUIs. Modern object-oriented programming languages can often be written and developed in a relatively short period of time. Object-oriented programming languages represent a new paradigm for software design. The object-oriented paradigm has arisen to enable faster development of complex software programs. It encourages the use of consistent interfaces between program modules, and is conducive to the creation of reusable, modular code. These features are highly advantageous in the creation of large, intricate software programs, requiring the coordinated effort of several programmers, and are particularly effective for GUI development.
Computer programs have traditionally been structured as a sequence of operations, which implements an algorithm or procedure. However, the object-oriented paradigm is based on objects, rather than procedures. The fundamental entities in an object-oriented programming (“OOP”) language are classes created by the programmer, which possess properties appropriate for their intended purpose. Once a class has been defined, one or more objects can be created as instances of the class. Individual objects possess all the attributes of the class they represent. For example, a software program for managing the inventory of a hardware store might contain objects such as nuts, bolts, screws, etc. having properties such as size, thread pattern, price, etc. In addition to their properties, objects also have methods. Methods are actions supported by the object, by means of which they interact with other objects or respond to external events. A major difference between OOP languages and traditional procedural program languages is that the methods and properties of an object are encapsulated. In object-oriented programming, encapsulation refers to the inclusion within an object of all the resources needed for the object to function—basically, the method and the properties. Other objects adhere to these interfaces to use the object without having to be concerned with how the object accomplishes it. This makes it easier to ensure that objects interface with one another in a consistent manner, and also protects the internal data of the object from unintentional corruption by other program elements. When an object is created, certain of its properties and methods are defined as “public,” and the remaining ones as “private.” Only the public properties and methods are accessible to other objects; the private properties and methods are protected.
Another feature of object-oriented programming languages that benefits code reusability is inheritance. The concept of inheritance is that certain classes or objects can inherit the properties and methods of a parent class or object. Thus, objects of code can be developed as modular building-blocks, with subsequent objects being children of parent objects. For example, a parent object when executed by a processor may produce an image indicative of an entire window and when executing a child object, the child object produces a sub-window, or template, within the parent object-executed window, or image. Importantly, the parent object can define a class, and the child object can inherit the class (properties and methods) of the parent object. In addition, the child object can also take on further methods and properties unique to the child object class. For example, a “jet” class can be defined as a child of an existing “airplane” class, with added properties, such as “turbine velocity.” Once the subclass exists, the programmer is free to create new objects with jet-like properties.
Some objects have a graphical representation. For example, it is common to include buttons, checkboxes, and other similar “controls” in a GUI belonging to an application program. Images associated with these objects are displayed on a computer screen to allow the user to interact with the application. Among the methods of such objects are display methods (e.g., “paintIcon”), which can be invoked to cause a graphical representation of the object to appear on the computer screen. To permit a user to interact with the GUI, displayable controls typically include methods enabling them to respond to external events, such as mouse button clicks. The object code that is the recipient of a user event (e.g., a pointer device placed over a button displayed on a computer display) is referred to as the target object. Thus, a target object can receive method-type code imparted to it when a user interacts with the GUI.
Java is a modem OOP language, based on an extensible hierarchy of classes. A given class within the hierarchy is deemed a parent to the classes beneath it, and a child of those above it. Classes inherit methods and properties from their parent class, and pass them on to their children. Child classes typically have additional methods and properties, beyond those of their parent. Java application programs create objects by instantiating classes, and interact with these objects via their methods and properties.
Java was designed with an emphasis on portability. As used herein, the term “platform” refers to a specific combination of hardware and operating system. More specifically, a platform consists of an operating system, the computer system's coordinating program, which in turn is built on the instruction set for a processor or microprocessor, the hardware that performs logic operations and manages data movement in the computer. A software program is said to be “portable” across various platforms if the program can run without modification on any of those platforms. This “write once—run anywhere” principle is the underlying philosophy behind OOP languages such as Java.
The portability of Java depends on the presence of a Java virtual machine (JVM) in the target computer (i.e., the computer on which the Java application is to execute). A JVM “translates” the generic Java code into instructions specific to the target machine (i.e., “native” code) at runtime. Therefore, the same Java program can run without modification on any computer for which a JVM exists.
Since its introduction, Java has found use in many areas, including GUI development, where the portability of Java code is highly advantageous. As used herein, the “look and feel” of a GUI refers to such things as the appearance, color and behavior of Buttons, TextFields, Listboxes, menus, etc. and their mouse, keyboard handling and behavior. Look and feel is the generic way in which to describe the appearance of an image on a computer display to that of another image on a computer display. If the window, icons contained within the window, the control menu, the general layout of that window, and the colors of the various features shown on that window are similar to that of another window image, then the two images are said to have essentially the same look and feel.
Often, a software program is intended to run on various machines, or under various operating systems, while maintaining a consistent look and feel. If the GUI is written in Java, a great deal of the code can be common across platforms, since Java is portable. The use of common code shortens development time, since the developer only has to write one version of the GUI code to be ported to all of the desired target machines or operating systems. It also improves maintainability of the code. When bug fixes or feature upgrades are necessary, they are confined to one version of the code, rather than several machine/system-specific versions.
Unfortunately, the portability of Java does not guarantee a completely consistent, platform independent look and feel for a Java-based GUI. This is because the GUI still derives some of the look and feel of the platform through its reliance on an application program interface (“API”). An API is an interface used by an application program to access operating system services. Therefore, API is an interface between the application program and the operating system, or platform. By making calls to the API, an application program can invoke the resources of the operating system, for example, to write to the computer screen or detect the position of the mouse cursor, or to request the current look and feel settings. Traditionally, Java applications utilize an API known as the abstract windowing toolkit (“AWT”).
Within the Java collection of classes, the AWT is represented by the following hierarchy of classes:
Within the AWT, and associated with each subclass of the Component class, are Component Peers, whose function is to provide a bridge between the portable Java code and the native (i.e., operating system specific) code that implements low level operations, such as graphics display functions and event routing, related to the GUI.
The fundamental user interface object in Java is the Component. As can be seen in the above hierarchy, the Component class includes the elements commonly associated with a GUI, such as Windows, Buttons, TextFields, etc. The functionality of the Component class can be broadly separated into appearance and behavior. The appearance of a Component is simply its graphical representation, when presented on a display device, such as a monitor screen. The behavior of a Component, on the other hand, relates to how the Component responds to user-driven events, such as clicking a mouse button when the cursor is positioned over the display area corresponding to the Component. Ultimately, both the appearance and the behavior of a Component are dependent on the AWT, since the AWT invokes the resources of the operating system to create a graphical representation for the Component and to properly route events related to the Component.
Ideally, the look and feel of objects created from the Component class (or any of its subclasses) in a Java application should be independent of the platform under which the application is running—i.e., the look and feel should be portable. But, as described above, the operating system environment is clearly a factor in both the appearance and behavior of these objects. A bridge between the platform independent objects and their platform dependent low-level implementation is provided by Component Peers.
A Peer is a type of software interface, represented in FIG. 1a. In this example, a Java application 10 is running within an operating environment 12. As shown in FIG. 1b, the operating environment is a computer system, containing a processor 34 and operating system 32, along with supporting hardware, such as a display device 16 and keyboard 18. Referring again to FIG. 1a, the application calls a method of a Component 14 that requires services specific to the operating environment. For example, the application 10 may interact with a user, which requires that it display a graphical representation of the Component 14. This is accomplished through the Component Peer 20, which is specifically designed to function within the operating environment 12 to provide the appearance and implement the behavior of Component 14. For example, to display the Component 14, the Java application 10 might employ a statement such as:                Component.setVisible(True);Note that this statement makes no reference to the graphics hardware in the computer, or any other specific features of the operating environment. These details are taken care of by the Component Peer 20. The Component Peer contains the native code instructions to display a graphical representation of the Component 14, using the specific graphics hardware and display device present in the operating environment. Whereas the Java statement is generic, and would be the same regardless of the operating environment within which application 10 is running, the corresponding Component Peer 20 is intimately connected with the operating environment through a library of operating system services, AWT.DLL 22. If the Java application 10 were ported to a different platform, the Peer 20 would have to be changed. Thus, it is convenient to think of the Peer mechanism as a software layer, providing a platform independent Application Interface 28, and a Host Platform Interface (HPI) 30 specific to the operating environment. The HPI 30 represents a boundary between platform independent Java code and the native code that invokes the low level services of the operating system. The Peer layer is part of the AWT 24 within the JVM 26.        
Peers are organized according to a class hierarchy, paralleling the AWT class hierarchy shown above, from the Component level down. Thus, there is a ComponentPeer class, which is sub-classed by the ButtonPeer, CanvasPeer, etc. Peer classes. Consequently, whenever an object is created as an instance of one of the Component classes or sub-classes, it has a counterpart Peer object.
Unfortunately, the Peer mechanism does not completely fulfill the goal of platform independence. Discrepancies in the HPI 30 exist between AWT versions intended for the various operating systems. These deviations result in variations in the appearance and behavior of the Java Components when an application is ported between platforms—in other words, look and feel inconsistency. Furthermore, the diverse implementations of the HPI 30 often contain quite different instruction sequences. These disparate codebases compound the difficulty for software developers of maintaining and enhancing the AWT.
Currently, IBM Java products require the following distinct AWT codebases:                sun.awt        sun.awt.windows        sun.awt.motif        sun.awt.os2        com.ibm.ibm4690These five separate implementations of the AWT share a great deal of the functionality of the Peer layer. However, the discrepancies in the native code implementation of the HPI set them apart and result in a unique set of Peer objects for each implementation. From the standpoint of look and feel consistency, as well as the software maintenance effort, it would be advantageous to be able to combine these distinct (but similar) codebases into a single generic AWT, consisting of a common set of Component Peers and a uniform HPI, allowing the generic AWT to be ported without modification to any supported platform.        